It is envisioned that 50 billion devices will be connected to the Internet in 2020 and that the Internet Of Things, IoT, where wireless devices such as sensors, light bulbs, etc. are connected, will be a major part of the connected devices. Security is very important for these wireless devices. For example, it is important to make sure that data delivered from sensors ends up in the right hands and that it has not been tampered with, and that sensitive data from these sensors is not exposed.
Another example is the need to prevent tampering of data sent to and from control devices such as door locks or pacemakers, for which tampering could have serious consequences on people's properties or health. Not only should the wireless device itself and the service provided by the wireless device be protected (e.g. secure communication between the wireless device and server to which the wireless device delivers sensitive sensor data), but also device management (such as SW update and configuration of the device) and service registration and enablement needs to be handled in a secure manner. Hence, it is important to prevent that a man-in-the-middle manipulates the SW, puts the wireless device into a faulty/unsecure configuration, or makes the wireless device register to a rogue server.
Wireless devices are typically constrained devices with limited computing and communication power and memory. For such wireless devices, several standards have been proposed in various standardization forums. One of these standards is the lightweight machine to machine, LwM2M, protocol that provides means for bootstrapping, registration, management, service enablement, and information reporting of constrained wireless devices. The LwM2M protocol runs on top of constrained application protocol, CoAP, which is a representation state transfer, REST-ful application protocol for constrained devices recently standardized by IETF. Both LwM2M and CoAP mandate the use of datagram transport layer security, DTLS for secure communication including mutual authentication between a wireless device and a server (bootstrapping server, device management server, or data reporting server).
CoAP and LwM2M specifications describe three modes in which DTLS is to be used and specify mandatory DTLS cipher suites to be used:                DTLS with pre-shared key: a pre-shared key between the wireless device and the server is used.        DTLS with public-private key pairs in raw-public-key, RPK, mode: both wireless device and server has an individual public-private elliptic curve cryptographic key pair used for mutual authentication and the RPK format is used to transfer keys between the IoT device and the server in order to avoid certificates and save memory and processing power in the wireless devices.        DTLS with certificates: both wireless device and server has individual public-private elliptic curve cryptographic key pairs and corresponding certificates certifying their public keys. Private keys and certificates are used for mutual authentication.        
To allow the constrained wireless device to establish DTLS session with different servers in any of these modes, it is necessary to provide credentials to the constrained wireless device such as a pre-shared key, a public-private key pair, and certificates. However, the constrained wireless device very often lacks interface and display for the user/enterprise that owns the device to be able to manually configure the wireless devices with credentials. Often, the only interface of a wireless device of machine type is the network interface. In many cases, the user/enterprise buys hundreds or thousands of wireless devices and then manual configuration of each device is too time consuming. Often, the wireless device may have been pre-configured with some credentials at the manufacturer of the wireless device but still need to be provided with device credentials that support the wireless device in securely operating in the user/enterprise network.
The phase in which the wireless device is initially provisioned with credentials is called the bootstrapping phase. In this phase, a bootstrapping server, BS, is involved in the provisioning of credentials to the wireless device. We consider the case where the wireless device is provisioned with an individual public-private key pair at manufacturing. For a secure bootstrapping, the manufacturer needs to provide the wireless device at manufacturing with a manufacturer public key/certificate such that mutual authentication is possible between the wireless device and the manufacturer BS (e.g. using DTLS) ensuring the device that it is communicating with a legitimate manufacturer BS server, and such that secure communication is established for delivering the user/enterprise BS URL and possibly credentials that are needed for the wireless device to securely connect to the user/enterprise BS. The wireless device may then proceed to the bootstrapping phase with the enterprise BS where provisioning of device credentials needed to securely connect to enterprise servers is done. To achieve a secure and successful bootstrapping with the enterprise BS, the wireless device and the enterprise BS are to mutually authenticate, and establish a secure connection for provision of the device credentials so that the wireless device can securely operate within the enterprise network. However, a protocol achieving a secure connection for credential provisioning needs to be as lightweight as possible to be supported by the wireless IoT devices.
US20150095648 shows a secure communication for “Machine-to-Machine”, M2M, between modules and servers. The module and server can utilize public key infrastructure (PKI) such as public keys to encrypt messages. The module and server can use private keys to generate digital signatures for datagrams sent and decrypt messages received. The module can internally derive pairs of private/public keys using cryptographic algorithms and a set of parameters. A server can use a shared secret key to authenticate the submission of derived public keys with an associated module identity. For the very first submission of a public key derived by the module, the shared secret key can comprise a pre-shared secret key which can be loaded into the module using a pre-shared secret key code. This document makes use of an additional pre-shared secret to transfer a public key generated at the module to the server, which is an additional cryptographic material. Having an additional cryptographic material is a sub-optimal solution for wireless IoT devices where resources are constrained and the amount or number of cryptographic material is to be kept to a minimum.
Hence, there is a need for a lightweight security protocol to enable secure provisioning of device credentials to a wireless device from a server.